Problems in Supporting Database Transactions in an Operating System Transaction Manager

Stonebraker, DuBourdieux, Edwards

Two-sentence summary: Stonebraker, et. al. points out 3 problems (mostly performance related) that come up when he attempted to use a transaction manager that was embedded in the OS instead of INGRESes own transaction manager. He concludes that OS-level transaction managers need to be extended to efficiently support DB transactions.

PRIMEOS + ROAM violate the end-to-end argument.

Definitions:
ROAM = an OS-level Transaction Manager (TM) that works by storing preimages and postimages of disk blocks in an undo/redo log. Concurrency done via 2PL (with locks only released at the end of transactions).

Problems:

1) Disk block/page writes. When only a specific record is modified in a disk block, ROAM has to store the postimage of the entire block, as opposed to just the modified record in the log, and this is a source of inefficiency.

So, they modified the system to only write out the modified record in a given disk block, but then the “line table” at the bottom of the page needs to be updated as well:

As a result, both the modified record, as well as the modification to the line table

needs to be logged to disk.

2) System Catalog Problems. Info about all relations, such as the number of tuples in each relation, are stored in a table called RELATIONS. Updating the number of tuples in a tuple of the RELATIONS relation requires that the entire relation corresponding to the tuple be locked. In addition, since locking is only provided at the disk block level, no other relations that share the same disk block in the RELATIONS relation can be updated concurrently. This results in massive (lack of) concurrency problems, since the appropriate disk blocks of the RELATIONS relation needs to be locked until after a transaction is complete.

To permit a reasonable level of concurrency, Stonebraker allowed special access to the RELATIONS relation (the system catalog) such that locks on this table do not need to be held until the end of a transaction. The disadvantage of this is that schedules are no longer guaranteed to be recoverable.

3) Coarse-grained rollbacks. In ROAM, if T1 updates a block and then T2 updates the block, but then T1 rolls back, the changes that T2 wrote are going to be lost even though it may have committed due to the fact that when T1 rolls back, the disk block is simply replaced by the preimage of the disk block that T1 stored in the log. Instead, a mechanism is needed whereby when the undo of T1 occurs, a blind disk block replace is not done, but instead, an appropriate undo action is computed on the disk block instead of a blind replace, so as to preserve T2’s committed updates to the block.

Stonebraker suggests the addition of “user-defined events” to be put into the log, and “user-defined” undo and redo handlers can be defined to undo or redo the events in the log when blind disk block replaces are not appropriate on rollbacks or roll-forwards.